Co-Simulation System Using a Slow Operation Mode that Allows Detailed Interaction with Hardware and a Fast Operation Mode

ABSTRACT

The invention relates to a hardware/software co-simulation system comprising a simulator and a hardware block coupled thereto with an I/O manager and at least one DUT (“Device under Test”), the co-simulation system comprising a first operating mode (Mode  1 ), wherein the I/O manager can forward a request from the simulator to the DUT on each clock cycle and a method for hardware/software co-simulation of a simulator with a synchronous electronic system. The aim of the invention is to improve the above such that the simulation times are significantly reduced. Said aim is achieved, whereby the co-simulation system comprises a second operating mode (Mode  2 ), wherein the I/O manager only forwards the clock signal (DUTC 1   k ) to the DUT without forwarding further requests to the DUT and a seamless switching between both operating modes (Mode  1 , Mode  2 ) is possible during a simulation.

The invention refers to a hardware/software co-simulation systemcomprising a simulator and a coupled hardware block which contains anI/O-manager and at least one DUT (“Device under Test”), whereas theco-simulation system has a first operation mode, at which theI/O-manager can forward a request from the simulator to that DUT atevery clock cycle, and to a method for a hardware/software co-simulationof a simulator with a clocked electronic system at which the simulatoris coupled with a hardware block having an I/O-manager and at least oneDUT (“device under test”) whereas in a first operation mode theI/O-manager is able to forward a request from the simulator to the DUTat every clock cycle.

Nowadays electronic developments grow increasingly complex because morepowerful functionality and simulations is required, but the developmenttimeframe stays the same or is even decreased. To guarantee the correctfunctionality of such a complex system, larger numbers of simulationruns are needed. To simulate the whole system it is necessary to run aco-simulation or to build a prototype.

Known hardware/software co-simulation systems that allow theco-simulation of a simulator with a clocked electronic system comprise asimulator and a coupled hardware block which contains an I/O-manager andat least one DUT (“device under test”). the DUT shall be integrated in arunning simulation of the simulator. A part of the simulator and theI/O-manager are responsible for the integration of the DUT as asimulation model in the simulation. State of the art systems use anI/O-manager that forwards one request from the simulator to the DUT atevery clock cycle. This is called a tight coupling, because of the datatransfer between the simulator and the coupled DUT that occurs at everyclock cycle. The drawback of the state of the art methodology is, thatthe simulation run times are often very long depending on the kind ofsimulation.

In contrast it is the object of the invention, to present ahardware/software co-simulation system and a method for ahardware/software co-simulation to decrease the simulation run timessignificantly.

The problem is solved by using the features of the independent claims.the hardware/software co-simulation system is comprising a simulator anda coupled hardware block having an I/O-manager and at least one DUT(“device under test”). The co-simulation system has a first operationmode at which the I/O-manager can forward a request from the simulatorto the DUT in every clock cycle. Furthermore according to the inventionthere is a second operation mode of the co-simulation system allowingthe I/O-manager to only send the clock (DUTClk) to the DUT, withoutsending further requests to the DUT, and a seamless switching betweenthese two operation modes is possible during a simulation. The inventionallows the acceleration of hardware/software co-simulations, by runningsimulations without the usually necessary tight coupling between thesoftware and the coupled hardware in this problem area. The tightcoupling means that at every clock cycle sent to the coupled system itis also possible to exchange additional data about the state of thecoupled system. The invention allows a seamless switching between thetight coupling and a loose coupling at which no data is transferredbetween the simulated software and the coupled hardware block. Only theclock signal is sent to the hardware to allow an accelerated simulationof the hardware. There is no limitation concerning the number ofpossible switches from the tight to the loose coupling during a runninghardware/software co-simulation.

The dependent claims concern advantageous embodiments of the invention.

The simulator is favorably a computer program running on a computer. Thecomputer system and the kind of computer program can be selected to beuseful in practical use.

The I/O-manager and the DUT can be located on the same or on differenthardware devices.

The invention can be used for the co-simulation of a simulator with aclocked electronic system, whereas the DUT is integrated in a runningsimulation of the simulator. a part of the simulator and the I/O-managerare responsible for the integration of the DUT in the simulation.

The concept of the invention can be subdivided in two modes ofoperation. in a first operation mode (co-simulation), corresponding to aconventional co-simulation, the I/O-manager can forward one request fromthe simulator to the DUT on every clock cycle leading to a tightcoupling between the simulator and the coupled DUT. In a secondoperation mode (clock acceleration) the simulation is running faster,because the I/O-manager sends only the clock (DUTClk) to the DUT. Nofurther requests are forwarded to the DUT in this operation mode. Thisoperation mode implements a loose coupling, because no other interactionhappens between the simulator (software part) and the coupled hardwarewhen the clock is offered at DUTClk.

According to a development, in the second operation mode a message fromthe simulator to the I/O-manager is possible concerning the number ofclock cycles that should be executed in the fast operation mode(NumOfClks) and/or concerning a breakpoint condition that depends on thecurrent state of the DUT.

A further development of this embodiment will use an I/O-manager with abreakpoint logic which examines the appearance of the breakpointcondition in the second operation mode.

A real acceleration of the co-simulation is particularly reached, whenthe generated DUTClk from the I/O-manager in the second operation modeis higher than the used clock in the first operation mode, i.e. it isalso higher than the clock frequency of the simulator (SimClk).

The invention is further explained in the drawings. It is shown in:

FIG. 1 a structure for the first operation mode (co-simulation),

FIG. 2 a structure for the second operation mode (clock acceleration),

FIG. 3 a timing diagram, showing both operation modes.

FIG. 1 shows the first operation mode 1 (co-simulation). in thisoperating mode it is possible to send a request in every clock cycle.this request is forward from the I/O-manager to the DUT. In the nextstep a clock edge is emitted on DUTClk. After each clock cycle aresponse is calculated by the I/O-manager and sent back to thesimulator. A bidirectional data transfer read/write is possible betweenthe I/O-manager and the DUT. the simulator can decide after each clockcycle, if the simulation should continue in mode 1 or in mode 2.

FIG. 2 shows the second operation mode 2. In this operation mode, thesimulator sends the number of clocks (NumOfClks) to be executed fast.Additionally it is possible to define a breakpoint condition thatdepends on the current state of the DUT.

As soon as the I/O-manager has received the number of clock cycles andthe optional breakpoint condition, it starts to emit clock edges onDUTClk. These clock edges in mode 2 use a higher clock frequency than inmode 1 (hence the name “clock acceleration” for mode two). Emittingclock edges on DUTClk is topped, as soon as one of the followingconditions is met:

the number of clock edges specified by NumOfClks was emitted.the condition specified by the breakpoint condition is met. Thiscondition is checked by the breakpoint logic of the I/O-manager all thetime.

There is only an unidirectional data exchange read between theI/O-manager and the DUT. After stopping the clock output on DUTClk, theI/O-manager sends a response back to the simulator. The simulator cannow decide, if the simulation should continue in mode 1 or in mode 2.

FIG. 3 is an exemplary timing diagram showing the simulator clock(SimClk), the clock that is sent from the I/O-manager to the DUT(DUTClk) as well as the request from the simulator to the I/O-managerand the response from the I/O-manager to the simulator.

The figure shows that in mode 1 the clock is generated by the simulator.in addition, data can be sent from the simulator to the DUT (request)and data can be sent from the DUT to the simulator (response) on everyclock cycle. However, in mode 2, the simulator only starts the emissionof clock edges on DUTClk. There is no interaction between theI/O-manager and the simulator during the emission of the clock edges onDUTClk. Only a response is sent to the simulator after the last clockedge is emitted or the break condition is met.

FIG. 3 further shows that it is possible to switch seamlessly betweenboth operation modes. The figure shows a small part of a simulationduring which much more clock edges are generated, of course.

1.-7. (canceled)
 8. A simulation system for simulating a device-undertest (DUT), comprising: a simulator operating at a clock frequency, ahardware block coupled to the simulator and comprising an I/O-Managerand at least one DUT, said I/O-Manager receiving requests from thesimulator, said hardware block, wherein in a first operating mode, theI/O-Manager transmits the requests to the DUT at every clock cycle, andin a second operation mode, the I/O-Manager transmits the clock cyclesto the DUT without transmitting the requests, and wherein the simulatoris configured to seamlessly switch between the first and secondoperating modes.
 9. The simulation system of claim 8, wherein theI/O-Manager and the DUT are located on the same device.
 10. Thesimulation system of claim 8, wherein the I/O-Manager and the DUT arelocated on different devices.
 11. The simulation system of claim 8,wherein in the second operation mode, the simulator indicates to theI/O-Manager a number of clock cycles that require fast execution or abreakpoint condition that depends on a current state of the DUT, orboth.
 12. The simulation system of claim 11, wherein the I/O-Manager hasa breakpoint logic that checks the breakpoint condition in the secondoperating mode.
 13. The simulation system of claim 8, wherein in thesecond operating mode (mode 2) the clock (DUTClk) emitted to the DUT bythe I/O-Manager has a higher frequency than the clock used in the firstoperation mode (mode 1).
 14. A method for simulating at least onedevice-under-test (DUT) with a simulator operating at a predeterminedclock frequency, said method comprising the steps of: coupling ahardware block to the simulator, said hardware block having anI/O-Manager and the at least one DUT, in a first operating mode, theI/O-Manager receiving a request from the simulator at every clock cycleand forwarding the request to the at least one DUT, and in a secondoperating mode, the I/O-Manager transmitting clock cycles to the DUTwithout forwarding requests to the at least one DUT, wherein switchingbetween the first and second operating modes is seamless during asimulation.
 15. The method of claim 14, wherein in the second operationmode, the simulator indicates to the I/O-Manager a number of clockcycles that require fast execution or a breakpoint condition thatdepends on a current state of the DUT, or both.
 16. The method of claim15, further comprising the step of checking in the second operation modethe breakpoint condition with a breakpoint logic that is part of theI/O-Manager.
 17. The method of claim 14, wherein the transmitted clockcycles in the second operating mode have a higher frequency than theclock cycles in the first operating mode.
 18. A computer programembodied on a computer-readable medium which causes a computer, afterthe program is loaded into computer memory, to cause the computer tosimulate at least one device-under-test (DUT), by: sending requests toan I/O-Manager connected between the computer and the at least one DUTat a predetermined clock rate, in a first operating mode, theI/O-Manager forwarding the received requests to the at least one DUT atthe predetermined clock rate, and in a second operating mode, theI/O-Manager transmitting clock cycles at the predetermined clock rate tothe at least one DUT, without also forwarding the received requests tothe at least one DUT, wherein switching between the first and secondoperating modes is seamless during a simulation.